Subject: FSMs and explorer messages

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Mon, 29 Aug 94 14:29:42 EDT

Reference: Note from Lakshman Garikapaty dated Wed, 27 Jul 94 15:10:22 EDT
           Note from Paul Brittain dated Wed, 3 Aug 94 18:30:11 BST

Lakshman, it appears that most of the changes you have proposed for the
FSMs involve the handling of explorer messages.  I had intentionally
had removed the explorer messages from the FSMs since they do not flow
for a particuler circuit.  I created a separate FSM to cover them.

Paul Brittain posted a much more robust FSM that documented the handling
of explorer messages.  It is well done, especially with respect to the
confusing issue of handling NETBIOS explorer messages.  I believe we
should keep the Explorer FSM separate from the Circuit FSM since they
document different things.  The Circuit FSM documents the handling of
end-to-end circuits, as identified by a pair of Circuit IDs.  The
Explorer FSM documents the handling of explorer messages which use
Data Link IDs for locating end stations.

I propose that we use Paul's FSM (attached below) with some modifications
that I have denoted with a SCK>.

EXPLORER FSM
============

The documentation of the *_ex messages seems insufficient to guarantee that
everyone interprets them in the same way.  The best way to avoid confusion
would be to define an 'explorer FSM' to handle these messages.  This could be
incorporated into the main FSM if desired as the process is largely independent
(hence the FSM merge is easy).  Pandian has already issued some FSMs along
these lines, but the NetBIOS issue above makes it unclear whether these are
the right FSMs to use.

In order to clarify the explorer frame processing, I have split out a separate
explorer FSM below.  We can use this to discuss whether the explorer processing
is as intended before deciding whether to merge it back into the main FSM.

In this FSM I have assumed

-       Cache is still optional.

-       Cache entries, if used, should be learnt at every opportunity.

-       A target DLSw may receive CUR/NQ_ex messages from many origin DLSws, so
        there is probably an FSM instance per Data Link ID/Origin DLSw pair
        (c.f. circuits where it is just per Data Link ID).  I have made no
        assumption about how this would be implemented.

-       Local retries of frames are absorbed/generated by a mechanism outside
        the scope of this FSM.

The states in the explorer FSM are:

RESET           -       initial state
SENT_EX         -       Sent an explorer frame
RECEIVED_EX     -       Received an explorer frame.
SENT_REC_EX     -       Sent and received explorer frame for same circuit
                        (For correct exchange of NetBIOS session numbers)

DLC events are as per the main FSM.

    RESET State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | If replying from    | If DLC_START_DL sent,|
    |                      | cache, send         |   RECEIVED_EX        |
    |                      | ICANREACH_ex        |                      |
    |                      | else if allowed to  |                      |
    |                      | test availability,  |                      |
    |                      | issue DLC_START_DL. |                      |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
SCK> I think we should avoid starting link stations (and using up
SCK> resources) for explorer messages.  I propose that we create a new
SCK> DLC action called DLC_RESOLVE_C that will generate a TEST command
SCK> for LAN DLCs (other DLC types can do as they wish).
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        | Send CANUREACH_ex   | SENT_EX              |
    | (i.e. not a frame    |                     |                      |
    |  that starts a circ.)|                     |                      |
SCK> Drop the (i.e. ...) part.
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    +----------------------+---------------------+----------------------+

    SENT_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | Send ICANREACH_ex   | RESET                |
    | (for same circuit in | DLC_RESOLVE_R       |                      |
    |  opposite direction) | Optionally update   |                      |
    |                      | cache               |                      |
SCK> I think this entry should be optional (i.e not in the FSM).
SCK> I think it would be simpler just to have this handled by another
SCK> FSM instance (since it is for a different Data Link ID) and just
SCK> have the DLSw generate a TEST command for the opposite direction
SCK> search and still wait for the ICANREACH_ex in this direction.
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | DLC_RESOLVE_R       | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RSP)  | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> NAME_RSP should be NAME_RECOG.
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        |                     | SENT_EX              |
    | (i.e. not a frame    |                     |                      |
    |  that starts a circ.)|                     |                      |
SCK> Drop the (i.e. ...) part.
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    | (different session   | Optionally update   |                      |
    |  number)             | cache               |                      |
SCK> How about changing (different session number) to (different local
SCK> session number than existing searches)?
    +----------------------+---------------------+----------------------+

    RECEIVED_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | Optionally update   | RECEIVED_EX          |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex |                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex|                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | DLC_DL_STARTED       | Send ICANREACH_ex   | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> If we do not start a link station for a CANUREACH_ex while in RESET
SCK> state (and send a DLC_RESOLVE_C instead) we can create a new DLC
SCK> event, DLC_RESOLVE_R, that indicates we have received a TEST
SCK> TEST response to our TEST command.
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        | Send ICANREACH_ex   | RESET                |
    | (opposite direction) | DLC_RESOLVE_R       |                      |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> I think this entry should be optional (i.e not in the FSM).
SCK> I think it would be simpler just to have this handled by another
SCK> FSM instance (since it is for a different Data Link ID) and just
SCK> have the DLSw generate a CANUREACH_ex for the opposite direction
SCK> search and still wait for the DLC_RESOLVE_R in this direction.
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RSP)  | Send NETBIOS_NR_ex  | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> NAME_RSP should be NAME_RECOG.
    +----------------------+---------------------+----------------------+

    SENT_REC_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RSP)  | RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> NAME_RSP should be NAME_RECOG.
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    | (different session   | Optionally update   |                      |
    |  number)             | cache               |                      |
SCK> How about changing (different session number) to (different local
SCK> session number than existing searches)?
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RSP)  | Send NETBIOS_NR_ex  | SENT_EX              |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
SCK> NAME_RSP should be NAME_RECOG.
    +----------------------+---------------------+----------------------+

Please post your opinions on whether this FSM appears correct, especially
with respect to NetBIOS session number exchanges.  We can then worry about how
to merge this with the main FSM.

---

From: Lakshman Garikapaty <[email-masked]>
Date: Tue, 30 Aug 1994 10:21:18 -0400

Hi Steve,

   If you take close look at Paul's FSM and the one i provided they pretty
much are doing the same thing. What i have done is combined both explorer
and regular messages into one FSM. I think it should be our goal to have
one fsm for ease of implementation. 

  What i think should be done is take my fsm as the base and fix any bugs
in them. If my fsm is not clear i can explain more, the general idea is
once the explorer messages are exhanged the state will circuit_start.
When you are in this state any dlc_resolve_c/canureach will return with 
ok status ie.  does not do any further processing. 

  Hope this helps.

  Lakshman.

---

From: "Steve Klein" <[email-masked]>
Date: Tue, 30 Aug 94 10:43:18 EDT

Reference: note from Lakshman Garikapaty dated Tue, 30 Aug 1994 10:21:18

Lakshman, I believe that combining the Explorer FSM with the Circuit
FSM will lead to more confusion than keeping them separate.  Paul's
Explorer FSM maintains search states for a particular Data Link ID
(Target MAC/SAP and Origin MAC/SAP).  The Circuit FSM maintains states
for a particular end-to-end circuit, identified by a Target Circuit ID
and an Origin Circuit ID.  The two FSMs cover entirely different
processing: the Explorer FSM describes processing necessary to maintain
topology information while the Circuit FSM describes the processing
necessary to establish circuits, tear down circuits, and transfer data
over circuits.

Connect RIGleteers, please post you opinions so we can have a GROUP
consensus on this issue.

Steve